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AMENDMENTS TO THE CLAIMS are reflected in the listing of claims which begins 
on page 43 of this paper. 

AMENDMENTS TO THE DRAWINGS are reflected in the attached drawings which 
begin on page 52 of this paper. These drawings are not page-numbered. 

THIS "REVISED RESPONSE TO 5 JUNE 2006 OFFICE ACTION" IS BEING 
SUBMITTED IN RESPONSE TO THE EXAMINER'S 12/28/06 OBJECTION TO 
FORM OF AMENDMENT. THE LINE SPACING OF THE APPLICANT'S 
"RESPONSE TO 5 JUNE 2006 OFFICE ACTION" HAS BEEN WIDENED; NO 
OTHER CHANGES HAVE BEEN MADE. 

REMARKS/ARGUMENTS 

I. CLAIM REJECTION - 35 U.S.C. S 101 

The Examiner's section 101 rejection is predicated on the Examiner's belief that the 
present disclosure is not patentable subject matter and is nonfunctional descriptive 
material. 

The Interim Guidelines for Examination of Patent Applications for Patent Subject Matter 
Eligibility "do not constitute substantive rulemaking and [] do not have the force and 
effect of law." (Guidelines, p. 2) To the extent the Examiner relied on the Guidelines as 
substantive or procedural law, the Applicant objects. 

For a review of patentability, the examiner is admonished to "review the totality of the 
evidence" including the specification, "before reaching a conclusion." (Guidelines, p. 24) 

The MPEP notes that "35 USC § 101 serves to ensure that patents are granted only on 
those inventions that are 'useful.'" As such, an invention must be "statutory subject 
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matter" and "the claimed invention" must be "useful for some purpose either explicitly or 
implicitly." (See MPEP 2107.01) "This can occur when an applicant fails to identify any 
specific and substantial utility for the invention or fails to disclose enough information 
about the invention to make its usefulness immediately apparent to those familiar with 
the technological field of the invention, [citations omitted] The second type of 
deficiency arises in the rare instance where an assertion of specific and substantial utility 
for the invention made by an applicant is not credible." (Id.) 

The Examiner has not made the assertion that the application's claim of utility is not 
credible (i.e., that it is wholly inoperative or 'incredible' or 'totally incapable of achieving 
a useful result'), thus this "second type" is not at issue in these proceedings. 

Thus, the Examiner is, essentially, arguing that "applicant fail[ed] to identify any specific 
and substantial utility for the invention." The Examiner cites MPEP 2106 (II)A, which 
deals with "non-functional descriptive material." 

With respect to computer-related disclosures, the MPEP provides guidance. It 
distinguishes between "functional descriptive material" and "nonfunctional descriptive 
material," stating that '"functional descriptive material' consists of data structures and 
computer programs which impart functionality when employed as a computer 
component." (MPEP 2106.01) 

Thus, the Examiner essentially claims that the present disclosure is "non-functional 
descriptive material." The Examiner makes the assertion, without citation, that "software, 
per se, is 'non-statutory subject matter' and claim 1 do [sic] not have 'practical application' 
because the 'final result' claimed ... is not producing 'useful, tangible and concrete' [sic] 
and therefore, claim 1 is a non-statutory subject matter." (First Office Action p. 5-6) 

"The tangible requirement does not necessarily mean that a claim must be tied to a 
particular machine or apparatus. . . ." (Guidelines, p.21) This should obviate the need for 
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the disclosure to state that a particular machine is an element, or, likewise, that a 
computer, disk drive, or other apparatus is an element. "When functional descriptive 
material is recorded on some computer-readable medium, it becomes structurally and 
functionally interrelated to the medium and will be statutory in most cases since use of 
the technology permits the function of the descriptive material to be realized." (MPEP 
2106.01) 

A.) THE SYSTEM'S DATA EXISTS, AND IS PROCESSED. STORED. AND 
USED. IN COMPUTER-READABLE MEDIA: 

In the computer science art area, it is common knowledge that computers—beyond their 
cases, boards, and wires—have tangible, useful elements to them, in the form of 
information. Information in a computer is made up of a collection of binary digits. These 
binary digits are represented by physical, positive and negative electrical states in 
hardware inside the processing and storage units of the computer. These electrical states 
are detectible, readable, interpretable, alterable, and useful. They exist in tangible media: 
the computer hardware. 

A computer program is a set of instructions for how these electrical states are changed— 
physically changed through altering electrical currents— to produce a specific result from 
a particular set of circumstances, some of which are inputted. 

Computer instructions and computer processes are "stored" in a tangible medium in the 
sense that computer instructions and processes reside in physical computer elements such 
as transistors or on chips. While this storage might be temporary, there is a definite 
physical state that is electro-magnetic in nature, in these physical computer elements. 

This is very analogous to computer "storage" with respect to information "stored" on a 
computer hard drive; storage on a hard drive is simply a collection of electronic states on 
a magnetic medium. After all, storage on a magnetic medium is a collection of 
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temporary magnetic flux patterns that are read by an electro-mechanical head moving 
over it. Like all things, this type of storage does not last forever: it is temporary in that it 
degrades over time. 

Likewise, an electromagnetic state in a transistor represents the storage of a bit of 
information. Just like a hard drive's flux pattern, the state is readable, meaningful, and 
useful, and exists in a physical realm. 

All of this is commonly known in this area of art and represents fundamental knowledge 
and practice in this art area. 

References to processing or making use of data which is in a computer readable format 
are implicit in the disclosure (reference can be made to the preceding paragraphs, as well 
as being generally known in the art) and are made in multiple paragraphs in the 
specification too numerous to mention, including paragraphs 0066, 67, and 68, as well as 
the representations made in all Tables used as examples in the specification. For 
example, "data might be processed so that it is tab or comma delineated, in ASCII text, 
converted between one file format or another or even edited. . . ." (See specification, 
paragraph 0068) 

In addition to references of processing data which is in a computer readable format, the 
present disclosure also notes the use of or transmitting data over electromagnetic carrier 
signals, such as in paragraphs 0066, 67, and 69. 

As such, the data in the present disclosure is in a computer-readable format and exist in a 
computer-readable medium: wires, transistors, chips, memory modules, disk drives. 
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B. ) THE SYSTEM HAS DISTINCT, PHYSICAL COMPONENTS, WHICH ARE 
CONCRETE AND TANGIBLE, WITHIN WHICH THE DATA IS PROCESSED, 
STORED, AND USED: 

As noted in the specification, paragraph 56, "Figure 1 illustrates in approximated physical 
form, [a] contact information Database System, 10, according to a preferred embodiment 
of the present invention." Further, a concrete, physical "Central Data Receiving and 
Storage Device, 12," is pointed out in paragraph 57 and Figure 1, as is "a Control 
Computer, 16," and a "Querying Device, 18." It is also noted that these elements "may 
be combined into the same physical device...." (See, specification, paragraph 0059) 
These elements are then explained further by their functionality, by referring to them 
collectively as the "Data Manager, 20." (See, specification, paragraphs 0060-61) 

As such, there are distinct and numerous examples where, in the specification, it is noted 
that physical elements, computer-readable data, and electromagnetic carrier signals are 
part of the disclosure. 

To reinforce this already-present situation, the Applicant has made amendments to 
Claims 1, 13, 23, 25, and 27, as shown in the amendments that follow. 

C. ) THE RETURNED INFORMATION IS USEFUL, CONCRETE, AND 
TANGIBLE: 

In the present disclosure, there is a "return" of contact information from a query (Claims 
1-12, 14-21, 24, and 26.) In Claims 13, 22, 23, 28-29, and 31-36, a "response" of contact 
information is "generated]" for a query. These items are discrete pieces of valuable 
information and are useful, concrete, tangible results. They are repeatable and 
predictable, and hence meet the test of In re Swartz, 232 F.3d 862, 864, 56 USPQ2d 
1703, 1704 (Fed. Cir. 2000). 
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This is abundantly clear in the specification and the examples are replete in the 
specification: "Any records that are found (preferably with different Email addresses than 
in the query) are returned to [the] Query Module for outputting to the Sender, typically in 
the form of a character string to be displayed as a printed response, as an update to the 
Sender's database, or as an electronic output file ." (Specification paragraph 0073, 
emphasis added) 

Moreover, the specification discusses, at length, how a physical embodiment of the 
present disclosure might be configured. See, e.g., Figure 1 and paragraphs 0056-60. 
Further, the specification makes it clear that the response or return to an inquiry (i.e., at 
the end of the processing of data) will be sent back to the inquiring party: ". . .once an 
alternative Email address or other data element is found it may be validated or authorized 
prior to delivery back to the Sender who inputted the initial query." (Specification 
paragraph 0132, emphasis added.) 

Additionally, Figure 1 clearly shows dual-directional arrows, between the Sender, 18 
(defined in paragraph 0006 as an entity "desiring communication with the Recipient" 
while a "Recipient," defined in paragraph 0004, is an entity "that changes [personally 
identifiable information] over time and with which communication is desired. . . .") and 
the Central Receiving and Storage Device, which is part of the primary embodiment of 
the present disclosure. Thus, there is clearly two-way communication between the 
physical embodiment and users who request information: a question (a "query," which is 
a term commonly used in the art) and an answer (a "return," which is also a term 
commonly used in the art). 

As is clear from the specification, the users of the system ("Sender") request contact 
information on a Recipient and get back contact information. This information is in the 
form of machine-readable code ("typically in the form of a character string," paragraph 
0073), which is in the form of digital information. The term "character string" is 
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commonly used in the art. This digital information is created by the system and 
transferred back to the Sender. This is clear from the specification. 

The result, or output or "return" or "response," from the computer program is, 
fundamentally, a set of positive and negative electric states in hardware, which are 
capable of being read and interpreted. As such, all results, outputs, returns, or responses 
from a computer program which is on some computer-readable medium is as much a 
discrete, useful, concrete, tangible result as any from a physical machine. To maintain 
otherwise is contrary to the guidelines of MPEP 2106.01. 

This fact is explicitly recognized with respect to Claim 1 , as the Examiner recognized the 
physical, "real world" nature of the claims, stating: "Claim 1 have [sic] the result of 
producing 'real world' results related to 'generating a response'. . . ." (First Office Action, 
p. 6 and 9) 

The Examiner appears to draw the distinction between a "real world" result and a 
"practical real world use," admitting that the disclosure has the first characteristic, but 
asserting it lacks the second. The Applicant has been unable to find such a distinction in 
the case law or MPEP. 

The usefulness of the return to the query is discussed in the specification, paragraphs 
000-0033, for example. 

Claims 1, 13, 23, 25, and 27 have been amended, as seen below. 

D.) THE PRESENT DISCLOSURE SOLVES PROBLEMS PRESENT IN THE 
PRIOR ART: 

As noted in the specification, there are at least three major, combined problems not 
solved by the prior art (see specification, paragraph 0018): a) people change contact 
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information fairly frequently and Email addresses even more frequently (see, e.g., 
specification, paragraphs 0003 and 0010); b) existing change of address systems require 
the person changing his/her contact information to notify the administrator of the system 
(see, e.g., specification, paragraphs 0010, 12, and 14); and c) existing change of address 
systems do not return/provide contact information of the same type as the query (see, e.g., 
specification, paragraph 0017) so that an inquiring entity can not get an Email address 
back in return for an Email address. 

As stated above, this is explained in the specification in paragraphs 0001 through 0033. 



II. CLAIM REJECTION - 35 U.S.C. § 102(b) 

For a section 102 rejection, the examiner is required to present a single reference that 
teaches or enables each and every one of the claimed elements, expressly or inherently, as 
interpreted by one of ordinary skill in the art. This type of objection can be overcome by 
demonstrating the claims are patentably distinguishable from the prior art or by amending 
the claims to the same end. See, for references, MPEP 2131. The Applicant here pursues 
both avenues. 

A.) THE TEACHINGS OF HERTZOG: 

The Examiner asserts that Hertzog (US Patent Application # 2003/0069874) teaches each 
and every element of the present disclosure. Hertzog is largely irrelevant to the present 
disclosure since it deals with updating a personal electronic address book. While it deals 
with accessing contact data from a database, in the form of a "virtual card," it works only 
with a graphical user interface and requires a user to manually determine what contact 
data the user requires. 
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B.) CLAIMS 1-24, 26, 28-29, 31-36: 

1.) Claim 1: 

a.) Hertzog does not describe an input consisting of "contact information." 

The present disclosure teaches a new way of finding alternate contact information when 
given other contact information. Points of contact are referred to as "personally 
identifiable information" or "PII," and described as one of the following: "postal 
addresses, telephone numbers, and internet electronic mail (Email) addresses, birth date, 
and governmentally-issued identification number (such as drivers license number, social 
security number, or passport number) used to identify" a "person, household, institution, 
or business." (Specification paragraph 0003) 

Contact information is used to describe and locate an entity. 

Hertzog does not describe inputting or querying using contact information. Hertzog does 
not describe returning contact information using an input or query consisting of contact 
information. 

Hertzog's query feature is limited to searching for the name of the contact, see Hertzog 
paragraph 0111. That is, Hertzog only teaches that one can search for a name in his 
electronic Rolodex and then return a "virtual card" with that person's address, phone 
number, etc. (Hertzog paragraph 0113). Specifically, Hertzog describes using a name 
inputted into the query (Hertzog paragraph 0111), and returning a virtual card. This is 
evident on Hertzog's figures, such as Hertzog Figs 8 through 9D. This is the identical 
functionality to Microsoft Outlook's search capability or any physical Rolodex. 
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Nowhere in Hertzog is a description of using point of contact information to find other 
contact information. Instead, his system uses only a name inputted to find a virtual card 
that might have points of contact on it. 

b.) Hertzog does not describe a means for "[identifying] alternate contact information 
of the same type as said query which is related to the entity". 

This element is not present anywhere in Hertzog. Nowhere in Hertzog's disclosure does 
he describe a means of identifying, say, an alternate address when the query is an address. 
Hertzog is limited to returning a card containing the same name as the query, and then the 
user must look at the card for the contact information. The "virtual card" that Hertzog 
describes contains multiple pieces of data. The user identifies the contact information 
that the user wants. Moreover, Hertzog's system does not return any particular or specific 
type of data, merely all the data associated with the queried name. 

There is nothing in Hertzog which describes how his disclosure goes about identifying 
the contact information within a virtual card, from amongst the other information about 
that individual. 

First, Hertzog requires a "graphical user interface" ("GUI") or a means of showing data 
on a screen. This required element is laid out in the disclosure repeatedly in Hertzog, 
starting Hertzog paragraph 0044, and further detailed in Hertzog paragraphs 0108 
onward, as well as Hertzog Figures 8 through 10, 24, 26, and 28. 

In essence, his system simply returns an entire "virtual card" containing all of the 
information associated with the name found in the query. In effect, a set of human eyes 
and a human brain are required to find the contact information on the virtual card 
returned by Hertzog. Useless and potentially useful information is returned and shown 
on a screen along with all the rest. There is no "identification " of individual data on a 
virtual card. 
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In the present disclosure, the use of the word "identify" makes it clear that some action on 
the part of the system is required, in order for a system to "identify" something. The 
Merriam- Webster defines the verb to mean "to conceive of as united. ..." The Encarta 
dictionary defines the verb to mean "to recognize . . .something and to be able to say 
. . .what . . .it is." The Oxford English Dictionary defines the verb to mean to "establish 
the identity of; [to] recognize or select by analysis. . . ." 

"Identification" requires some type of action. In Hertzog, the only "identification" is 
implied—the user undertakes all identification manually— because this identification takes 
place outside of the disclosure in Hertzog. 

Hertzog is antithetical to the present disclosure. The present disclosure requires an 
input/query of contact information, and then a return of contact information from that 
query. Specifically, the present disclosure requires a "means for accessing and searching 
said database that . . .identifies alternative contact information of the same type as said 
query which is related to the entity. ..." In the present disclosure, the system "identifies 
alternate contact information of the same type as said query which is related to the 
entity". 

The present disclosure teaches two things Hertzog does not do: it picks out ("identifies") 
contact information from amongst surrounding data related to a single individual, and 
returns that specific type of data (i.e., data of the same type as the query data). 

c.) Hertzog does not teach returning a specific type of data to the exclusion of other 
data. 

As noted above, Hertzog returns a virtual card, containing both potentially useful and 
some useless data visually to a human user. 
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The present disclosure is much more targeted and automatic. By requiring "a third means 
for responding to queries that returns, in response to said query, different contact 
information of the same type as said query, said different contact information 
corresponding to the same entity as said query," the present disclosure requires a return 
of a specific type of data about the same individual as in the query. 

Hertzog's shotgun approach to returning data is logical for a Rolodex system but has 
nothing to do with the present disclosure's automatic look-up process. There is no 
requirement in Hertzog that a query return data of the same type as in the query. This 
may or may not happen and is ultimately irrelevant to Hertzog, who teaches only 
returning a whole virtual card. Further, Hertzog's system does not know what it is 
returning, since it returns all related data, leaving a human user to sort through the useless 
data. For example, if a user of Hertzog's system wanted only an email address, that user 
would have to visually scan down the virtual card to find the email address, effectively 
hidden amongst the physical address data, the phone number data, etc. The present 
disclosure, therefore, contains a limitation and functionality not present in Hertzog and 
not taught by Hertzog. 

d. ) Hertzog discloses a data storage means. 

Data storage was not first disclosed by Hertzog, rather, it is a fundamental element 
present in every computer ever devised. Data storage means are necessary for the 
operation of all computer equipment, even if just to store some basic operating 
instructions. In this regard, Hertzog does not teach anything different from the prior art. 

e. ) Hertzog discloses a database of contact information for a plurality of entities. 

Here, again, databases were not first disclosed by Hertzog, rather a database is a 
fundamental element of every address book system ever devised, whether in paper or 
electronic form. 
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Moreover, the Examiner asserts that Hertzog teaches a database having multiple data sets 
and fields "related to" personal information "attributes." If the Examiner is saying that 
Hertzog discloses a database with multiple data sets consisting of multiple fields 
consisting of individual items of personal contact data, this, too, was not first disclosed 
by Hertzog, but is the very definition of an address book, certainly dating back as far in 
time in the world as there were street addresses. 

f. ) Hertzog discloses an ability for information in a database to be accessed by a 
database management system which executes database queries. 

Here, again, accessing database information was not first disclosed by Hertzog, rather it 
is a fundamental element of every database system ever devised. A database without a 
querying function is useless. 

g. ) Hertzog discloses a means of searching a database by comparing the contents with 
a search string. (First Office Action, first paragraph, page 13.) 

If the Examiner is asserting the above, then, once again, Hertzog was certainly not the 
first to disclose this basic functionality of all electronic database systems. Essentially, 
what Hertzog teaches is a simple word search through a Microsoft Outlook address book. 
Since this element was already present in Outlook prior to Hertzog's "disclosure," 
Hertzog was not first to disclose it. 

h. ) Hertzog does not teach a means for responding to queries, returning different 
contact information of the same type as the query. 

Hertzog does not contain this limitation or functionality in his disclosure. Hertzog's 
query feature is not required to return different contact information of the same type as 
the query. In fact, Hertzog's query feature does not require a return of particular contact 
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information. Where a return occurs in Hertzog, it is typically of contact information of a 
different type as the query. Hertzog uses an unsophisticated return: input a name search 
string and return the virtual card where that name search string appears. 

In contrast, the present disclosure details a "return[], in response to [a] query, different 
contact information of the same type as the query. . . ." This limitation is not taught by 
Hertzog. 

Further, Hertzog's query feature requires a return of data on a graphical user interface, 
called a "browser panel" by Hertzog. This feature is evident in Hertzog Figs 8 through 
9D, and present in Hertzog paragraph 01 13 et seq. 

In the present disclosure, there is no such "virtual card," and no name-based "power 
find." This idea is antithetical to the present disclosure. Hertzog's return of data would 
render the object of the present disclosure useless. 

In summary, Hertzog does not teach or enable each and every one of the claimed 
elements of Claim 1, expressly or inherently, as interpreted by one of ordinary skill in the 
art. 

2.) Claim 2: 

The above arguments are equally valid with respect to Claim 2, thus, rather than repeat 
each and every argument, the Applicant incorporates them here by reference. 

a.) Hertzog does not teach "a means for identifying contact information of a second type 
which is related to the same entity as said query." 
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The arguments from above apply equally to this item. In summary, Hertzog teaches no 
means of identifying any particular data. Identification of data is left wholly to the 
human user to be done manually. 

The Examiner's citation of Hertzog paragraphs 0113 and 01 15 is irrelevant to this point. 
That text states only that a human user can look at a screen displaying a virtual card and 
select the virtual card itself as belonging to a certain classification, such as a business 
contact or a personal contact. It's merely a way for a human user to manually sort virtual 
cards, thereby distinguishing between different cards, and has nothing whatsoever to do 
with identification of data within or on a virtual card. Thus, Hertzog is irrelevant to, say, 
identifying a physical address related to a specific individual after searching using the 
specific individual's email address. The Hertzog paragraphs cited by the Examiner deal 
with distinguishing between different individuals, not different data regarding the same 
individual. 

b.) Hertzog does not teach "a means for searching through said database, using said 
second type of personal contact information." 

Once again, since Hertzog relies entirely upon a human user to decide what they're 
looking for, there is no disclosure dealing with how, for example, the system might 
search using an email address, find a related physical address, then search the database a 
second time to find Email addresses related to that physical address. 

These steps can not be performed by Hertzog's disclosure and are not disclosed in 
Hertzog. Once again, Hertzog returns a virtual card and the rest is up to the human user. 
The Examiner's citation of Hertzog paragraph 01 16 is irrelevant, since that paragraph 
deals only with the parts of the virtual card, not with any searching capability. 
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c.) Hertzog does not teach "a means for identifying, in the database, alternate contact 
information of the first type in said query which is related to said second type of personal 
contact information, for the same entity." 

The Examiner's citation of Hertzog paragraph 0116 and Figure 9A is irrelevant here too. 
Each clause in the same claim must be read in conjunction with the other clauses in the 
same claim. An example regarding this part of the present disclosure might be clarifying: 
a search is done using an email address; a physical address is returned; a search is done 
using the physical address, which leads to the discovery of a related email address; which 
is identified and returned. This type of hypothetical example is explained in the present 
disclosure at paragraphs 0120 onward. 

The Examiner's citations do not support the Examiner's assertions. Hertzog does not 
teach the "append-reverse-append" procedure described in the present disclosure. (See, 
e.g., paragraph 0026, et seq., in the present disclosure.) 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 2, expressly or inherently, as interpreted by one of ordinary skill in the art. 

3.) Claim 3: 

Claim 3 is a dependent claim, and ultimately depends upon Claim 1 . The arguments 
presented above are incorporated herein. 

Hertzog does not describe "a means for repeating said searching and said identifying 
means, until all related contact information of the type in said query for said entity is 
identified in said database." 

There is no suggestion in Hertzog regarding repeated searching using data identified 
during a prior search. 
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The Examiner's citation of Hertzog paragraph 0109 is irrelevant to this element. That 
paragraph deals with the screen result of a query in Hertzog. It reveals what Hertzog's 
search output is: a screen shot of a Rolodex-style virtual card. All identification in 
Hertzog is done manually by a human user looking at a screen. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 3, expressly or inherently, as interpreted by one of ordinary skill in the art. 

4.) Claim 4: 

Claim 4 is a dependent claim, and ultimately depends upon Claim 1 . The arguments 
presented above are incorporated herein. 

Nowhere in Hertzog is described a "means for selecting a single one amongst more than 
one alternate contact information elements". Hertzog describes merely a means of 
presenting a virtual card that's been chosen in a word search. Any "selection means" 
amongst alternate contact points in Hertzog is the brain of the person looking at the 
virtual card; Hertzog requires human eyes and brain to make this selection. This is 
neither described or implicit in Hertzog. 

The Examiner appears to confuse the concepts of finding a name on a virtual card- 
selecting between cards/entities—and identifying specific data amongst that for a 
particular entity. Put another way, Hertzog teaches how to thumb through a Rolodex, 
looking for the name you wanted to find. But Hertzog does not teach how—once you 
found the card with the right name— to distinguish between, say, that entity's address and 
their phone number. That is left to the user. As such, Hertzog does not teach or enable 
each and every one of the claimed elements of Claim 4, expressly or inherently, as 
interpreted by one of ordinary skill in the art. 
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5. ) Claims 5-8: 

Claims 5 through 8 are dependent claims, and ultimately all depend upon Claim 1 . The 
arguments presented above are incorporated herein. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claims 5-8, expressly or inherently. 

6. ) Claims 9-12: 

Claims 9 through 12 are dependent claims, and ultimately all depend upon Claim 1 (as 
well as Claims 2-4). The arguments presented above are incorporated herein. 

Moreover, Hertzog discloses only that users can "grant permission to access. . .personal 
information" when the virtual card is created. See Hertzog, paragraph 72. Hertzog 
discusses "published" and "nonpublished" fields. (See, e.g., Hertzog paragraph 76) 

This is antithetical to the present disclosure which does not use such virtual cards and 
user-created entries in a database at all. Hertzog's disclosure is unlike the present 
disclosure, and actually akin to permissions granted by the CHMOD function, which 
dates back to the early days of the UNIX operating system. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claims 9-12, expressly or inherently. 

7.) Claims 13, 23: 

The Examiners review of these claims and the disclosure in Hertzog reveals a 
fundamental misunderstanding of what Hertzog discloses. 



19 of 53 



Appl. No. 10/605,488 

REVISED Amdt. dated 28 FEBRUARY 2007 
Reply to Office action of 5 June 2006. 

The arguments presented above, in conjunction with Claims 1 and 2 in particular, are 
incorporated herein. 

As such, without being unduly repetitive, it is necessary to point out that Hertzog does 
not teach "identifying, in said database, one or more alternative contact information 
elements of the first type related to the entity in said query by using said second type of 
related contact information to search said database." Hertzog does not teach a means for 
identifying alternative contact information. 

It is also necessary to point out that Hertzog does not "generate] a response indicating 
that alternate contact information of the first type for said entity is not included in said 
database." The Examiner's citation to Hertzog paragraph 106 is irrelevant to this element. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claims 13 and 23, expressly or inherently. 

8.) Claim 14: 

Claim 14 is a dependent claim, and ultimately depends upon Claim 1 (as well as Claim 
9). The arguments presented above are incorporated herein. 

The Examiner misunderstands Hertzog as respects this Claim. The Examiner cites 
Hertzog's paragraph 107, which deals only with updates to Hertzog's database. It has 
nothing whatsoever to do with recursive, repetitive searches to a database. 

The present disclosure, in Claim 14, is well known—in the relevant area of art—as a 
recursive search, "repeatedly searching the database, using said second type of contact 
information and alternate contact information of said first type for repeatedly searching 
said database, until all related contact information of said first type for said entity is 
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identified in said database." Search results, rather than simply being displayed to a user 
like in Hertzog, are identified and used to repeatedly search the database. 

Nothing in Hertzog even remotely resembles this element or limitation. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 14, expressly or inherently. 

9. ) Claim 15: 

Claim 15 is a dependent claim, and ultimately depends upon Claim 1 (as well as Claim 
9). The arguments presented above are incorporated herein. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 15, expressly or inherently. 

10. ) Claim 16: 

Claim 16 is a dependent claim, and ultimately depends upon Claim 1 (as well as Claims 
2, 3, and 11). The arguments presented above are incorporated herein. 

It is necessary to point out that Hertzog does not teach "generating and transmitting a 
permission request" to reveal resulting contact information. On the contrary, Hertzog 
discloses only that users can "grant permission to access. . .personal information" before 
the inquiry takes place, when the virtual card is created. See Hertzog, paragraph 72. In 
fact, Hertzog discusses "published" and "nonpublished" fields. (See, e.g., Hertzog 
paragraph 76) This is antithetical to the present disclosure, which does not use such 
virtual cards and user-created entries in a database. 



21 of 53 



Appl. No. 10/605,488 

REVISED Amdt. dated 28 FEBRUARY 2007 
Reply to Office action of 5 June 2006. 

The Examiner's citation of Hertzog paragraph 87 is irrelevant to this element. That 
paragraph deals only with the relationship between tables in Hertzog's database. 

It is further necessary to point out that Hertzog does not contain the following limitation: 
"discarding contact information for said entity from said response, if said permission is 
not obtained." Hertzog does not teach or disclose this limitation. 

The Examiner's citation of Hertzog paragraph 88 is irrelevant to this element. That 
paragraph deals only with the relationship between tables in Hertzog's database. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 16, expressly or inherently. 

11.) Claim 17: 

Claim 17 is a dependent claim, and ultimately depends upon Claim 1, as well as Claim 9. 
The arguments presented above are incorporated herein. 

As noted above, Hertzog does not teach any "identification" step or means, other than 
impliedly requiring a human brain and eyes to do this manually. 

The Examiner's citation of Hertzog paragraph 89 is irrelevant to this element. That 
paragraph deals only with a user updating another's database entry in Hertzog's database. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 17, expressly or inherently. 
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12.) Claims 18-21: 

Claims 18 through 21 are dependent claims, and ultimately all depend upon Claim 1 (as 
well as Claims 2-4, 9, 10, 11, and 12, respectively). The arguments presented above are 
incorporated herein. 

The Examiner's citation of Hertzog paragraph 141 is telling in that it highlights how 
Hertzog is anchored solely upon the display of a virtual card to a user. This paragraph, 
completely irrelevant to the elements disclosed in Claims 18-21, deals with how a user 
can fill in his virtual card, using a typical Windows dialog box, to put into the database. 
This paragraph and the entire concept of a displayed virtual card are utterly antithetical to 
the present disclosure. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claims 18-21, expressly or inherently. 

13.) Claim 22: 

Claim 22 is a dependent claim, and ultimately depends upon Claim 13. The arguments 
presented above are incorporated herein. 

As noted above, the Examiner's citation of Hertzog paragraph 141 is irrelevant to the 
elements in this Claim because it deals with how a user can fill in his virtual card, using a 
typical Windows dialog box, to put into the database. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 22, expressly or inherently. 
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14. ) Claim 23: 

The Examiner has made no specific § 102 rejection of Claim 23; as such, the Examiner 
has not clearly articulated the rejection as to that claim. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

Should the Examiner have specific arguments regarding a specific rejection of Claim 23, 
the Applicant asks for leave to respond. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 23, expressly or inherently, as interpreted by one of ordinary skill in the art. 

15. ) Claim 24: 

The Examiner has made no specific § 102 rejection of Claim 24; as such, the Examiner 
has not clearly articulated the rejection as to that claim. 

Should the Examiner have specific arguments regarding a specific rejection of Claim 24, 
the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 24, expressly or inherently, as interpreted by one of ordinary skill in the art. 

16. ) Claim 25: 

The Examiner has made no § 102 rejection of Claim 25. 
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17. ) Claim 26: 

Claim 26 is a dependent claim, and depends upon Claims 1 and 4, 12, and 21. The 
arguments presented above are incorporated herein. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 26, expressly or inherently. 

18. ) Claim 27: 

The Examiner has made no § 102 rejection of Claim 27. 

19. ) Claim 28: 

Claim 28 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 objection to Claim 23. Claim 28 discloses further limitations upon Claim 
23. 

Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 28, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 28, expressly or inherently. 

20. ) Claim 29: 

Claim 29 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 29 discloses further limitations upon Claim 
23. 
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Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 29, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 29, expressly or inherently. 

21. ) Claim 30: 

The Examiner has made no § 102 rejection of Claim 30. 

Claim 30 has been amended to be dependant of Claim 29, correcting a typographical 
error. 

22. ) Claim 31: 

Claim 31 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 31 discloses further limitations upon Claim 
23. 

Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 31, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

The Examiner's citation of Hertzog paragraph 71 is irrelevant to this Claim. That 
paragraph deals solely with the input of "master" data into Hertzog's database, using a 
GUI (graphical user interface). The Claim in the present disclosure describes "grouping 
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each record of each dataset with other records in the dataset and/or records in the 
database by contact information," so that the searching function is made easier. Hertzog 
does not teach any automatic grouping functionality; it implicitly relies upon a user to 
manually update information on the virtual card and then these changes are tracked. 
Further, there is no merging functionality in Hertzog which would prevent two or more 
instances of data for the same entity. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 3 1 , expressly or inherently. 

23.) Claim 32: 

Claim 32 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 32 discloses further limitations upon Claim 
23. 

Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 32, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

The Examiner's citation of Hertzog, paragraph 125, does not teach "identifying all 
received data records as candidates for merging in the database". In fact, it deals with a 
"send" button in Hertzog's disclosure, which allows for emailing or faxing an address 
card. This citation is irrelevant to the present disclosure. There is simply no parallel 
function in the present disclosure for obvious reasons: there is no user of a 'personal 
information management application' to contend with. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 32, expressly or inherently. 
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24. ) Claim 33: 

Claim 33 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 33 discloses further limitations upon Claim 
23. 

Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 33, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

While Hertzog, paragraph 42, as cited by the Examiner, deals with the use of one or more 
computers to run parts of Hertzog's disclosure, it does not teach with the use of "a 
computing device" to identify an entity in the database described in the present disclosure 
that matches the entity in the particular query used in this disclosure and is associated 
with the contact information in the particular query used in this disclosure. That is, 
Hertzog's computer does not perform the tasks that the computer performs in the present 
disclosure. As such, the citation of Hertzog is irrelevant to Claim 33. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 33, expressly or inherently. 

25. ) Claim 34: 

Claim 34 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 34 discloses further limitations upon Claim 
23. 
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Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 34, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

The Examiner's citation of Hertzog, paragraph 55, is inapplicable because it deals with 
synchronization of local and external databases, and it does not teach "identifying" data 
by "comparing similar, but inexact, contact data elements to determine if the data 
elements are equivalent." This is the application of fuzzy logic to make data 
comparisons. See, e.g., the present disclosure, paragraph 183. There is no teaching of 
this anywhere in Hertzog. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 34, expressly or inherently. 

26.) Claim 35: 

Claim 35 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 35 discloses further limitations upon Claim 
23. 

Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 35, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

Hertzog, in paragraphs 55, 66-67, does not teach "inserting each one of plurality of 
selected contact information elements and relationships between contact information 
elements and entities". Indeed, those paragraphs in Hertzog deal with adding new users 
(a feature that does not exist in the present disclosure because there are no system "users" 
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in the same sense as in Hertzog) and updating and synchronizing contacts (which, since it 
is a function performed by a user of Hertzog's virtual card system, is irrelevant to the 
present disclosure, since "users" of the present system don't update or synchronize the 
database or a 'personal information management system' themselves). Moreover, 
Hertzog's disclosure deals with synchronization between a locally stored database and a 
central database, requiring at least two databases. The present disclosure teaches a single 
database and there is no such synchronization. 

Perhaps most importantly, Hertzog's disclosure does not teach with automatically 
inserting missing info into the database if a search comes up empty. Note that the present 
disclosure's Claim 35 teaches an insert performed in conjunction with Claim 23 (d)'s 
response to a failed query. There is no such functionality in Hertzog. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 35, expressly or inherently. 

27.) Claim 36: 

Claim 36 is a dependent claim, and depends upon Claim 23. The Examiner has made no 
specific § 102 rejection of Claim 23. Claim 36 discloses further limitations upon Claim 
23. 

Should the Examiner have specific arguments regarding a specific rejection of Claims 23 
or 36, the Applicant asks for leave to respond. 

With respect to this rejection, the applicant incorporates his above arguments herein. 

Hertzog does not teach periodically receiving a plurality of datasets and processing them 
in the manner set forth in the present disclosure. The Examiner cites paragraph 0075 of 
Hertzog for the proposition that Claim 36 has been disclosed. Hertzog's paragraph 0075 
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says merely that the "receiving user's" database "may. . .be populated. . .by personal 
information to which the receiving user has been granted access." Nothing is said in 
Hertzog about the other processing steps taught by Claim 36, such as the ones taught by 
Claim 23, to which the Examiner correctly makes no § 102 objection. 

As such, Hertzog does not teach or enable each and every one of the claimed elements of 
Claim 36, expressly or inherently. 



III. CLAIM REJECTION - 35 U.S.C. $ 103 

The Examiner is required to show one or more references that teach a suggestion to 
combine or modify the references, making the present claims obvious. The combination 
in turn must teach or suggest all the claim limitations. 

The Applicant incorporates his above arguments herein. 

A. ) THE PRESENT DISCLOSURE DOES NOT NAME JOINT INVENTORS. 

The present disclosure names a single inventor: Thomas R. Burke. The Examiner's 
statement to the contrary is incorrect. 

B. ) CLAIMS 25, 27, AND 30 AND THE TEACHINGS OF HERTZOG, IN 
CONJUNCTION WITH SMITH 

The Examiner must look at whether the present disclosure as a whole is obvious, in light 
of the references. (MPEP 2141.02) 
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Here, the Examiner asserts that Hertzog is relevant prior art to the present disclosure. 
However, essentially, Hertzog teaches only a disclosure that allows a consumer user to 
view and synchronize their personal address books on multiple computers, using a 
graphical user interface and virtual Rolodex-like cards. 

Hertzog does not teach querying and identifying and returning updated contact 
information of a particular type from a database, using contact information of the same 
type. 

There are multiple, required elements of Hertzog which are not present in the present 
disclosure and demonstrate that Hertzog deals with a completely different problem and 
solution. As such, the present disclosure is certainly not rendered obvious from the 
disclosure of Hertzog. 

Smith's disclosure, on the other hand, deals solely with authentication procedures for 
being able to access a database. It is a password-protection system, nothing more. It has 
very limited relevance to the present discussion, if any. 

Also, the Examiner must put forth a reasonable expectation of success in the combination 
of references (see MPEP 706.02(j)). This was not done. 

The Examiner asserts that Hertzog teaches a system for populating and maintaining a 
contact information database and, in conjunction with Smith (US Patent Application # 
2003/0069874), the combination teaches the present disclosure. 

The present disclosure teaches limitations that are not present in either Smith or Hertzog, 
and not suggested by either. 
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1.) Hertzog's requirement of a "personal information management application" 
teaches away from the present disclosure. 

Hertzog is, at its heart, a way for a consumer to have several personal address books in 
several different locations or different computers. Hertzog, as such, requires the 
existence and use of an application where the consumer puts his address book (see 
Hertzog, Claims 1 and 9). Hertzog calls this a "personal information management 
application" ("PIM" application). Hertzog specifies this PIM application be one of the 
following applications: Microsoft Outlook (Hertzog paragraph 0005, 0043), Lotus Notes 
(Hertzog paragraph 0043), Palm Desktop (Hertzog paragraph 0046). These are, 
essentially, consumer-focused applications. The "personal information management 
application" is the digital version of a Rolodex, nothing more. (See, e.g., Hertzog, 
paragraph 0004: "Where a user has multiple devices each storing a local copy of personal 
information. . ." or Hertzog paragraph 0003: "the need to maintain multiple, synchronized 
copies of [] personal information. . .on. . .a personal computer. . .a portable PDA. . .or. . .via 
a network.") 

The present disclosure functions without any "personal information management 
application" whatsoever. The present disclosure teaches how a third party might find out 
what someone's new email address was, similar to the way they might find out a person's 
new address from the US Postal Service, after they moved. In contrast, Hertzog teaches 
how a person might make a change in their own Rolodex once they move around. It is 
absolutely irrelevant to the present disclosure how a person stores their address 
information for their own personal use. 

Since the present disclosure does not require or use a consumer-based application, 
Hertzog teaches away from the present disclosure. Moreover, Hertzog's requirement has 
no logical analog in the present disclosure; this feature is completely irrelevant to the 
present disclosure. These are not requirements of the present disclosure, and, hence, 
Hertzog and Smith teach away from the present disclosure. 



33 of 53 



Appl. No. 10/605,488 

REVISED Amdt. dated 28 FEBRUARY 2007 
Reply to Office action of 5 June 2006. 



2.) Hertzog's requirement of "personal information" validated by a "personal 
information management application" teaches away from the present disclosure. 

As mentioned previously, Hertzog is, at its heart, an application that allows a consumer to 
have several address books in several different locations or different computers. Hertzog, 
as such, requires a user with their own personal information inputted onto a virtual card 
in a database and shared; and Hertzog goes a step further by requiring that the consumer 
user "validate" by logging into a "personal information management application" with a 
password (see, e.g., Hertzog claims 9 and 10 and Hertzog paragraphs 0008 and 0064). 
Hertzog does this to prevent multiple accessing of his database at once. 

The present disclosure does not require such a validation and there is no logical analog 
between this "validation" and the present disclosure. It is irrelevant because of the lack 
of multiple databases in the present disclosure. Requirements for multiple databases 
teach away from a single database structure. As such, this feature is irrelevant to the 
present disclosure and, hence, Hertzog and Smith teach away from the present disclosure. 

3.) Hertzog's requirement of particular "event occurrences" teaches away from the 

present disclosure. 

Since Hertzog teaches an updater for a person's address book, it requires an "event 
occurrence" which is, essentially, data inputted on a particular day (see, e.g., Hertzog 
claims 1, 2, 4, 8, 9, and 10). When different data is inputted on another day, or at another 
time, another "event occurrence" has happened. Thus, Hertzog requires data inputted at 
two different times and requires that the data be synchronized between two different 
databases. Again, this time differential idea is important for Hertzog because he's using 
multiple databases accessed from different locations at different times. Hertzog has to 
monitor these different times to make sure his multiple databases are properly 
synchronized. 
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These are not requirements of the present disclosure. Multiple databases, multiple 
'personal information management applications,' and logging in from different locations 
at different times are requirements of Hertzog that teach away from the present 
disclosure. For the present disclosure, a timing difference is not required. The present 
disclosure requires alternate contact data of the same type as the inputted data. The 
present disclosure has nothing to do with synchronization of the same data at two 
different time periods or on two different computers; no time difference is necessary. 

By way of example, in the present disclosure, the database could contain information 
from one slice of time and still function. It would work perfectly well if an entity in the 
database had multiple types of contact data, for example, more than one Email address, 
from the same time slice. 

Hence, Hertzog teaches away from the present disclosure by requiring a time differential 
between data elements. Hertzog's requirement has no logical analog in the present 
disclosure. These are not requirements of the present disclosure, and, hence, Hertzog and 
Smith teach away from the present disclosure. 

4.) Hertzog's requirement of "non-simultaneous validation" by a user teaches away 

from the present disclosure. 

Since Hertzog deals with a consumer being able to synchronize their personal address 
books on multiple computers or applications, Hertzog requires that the user not be logged 
into their address books on these various computers at the same time. A logical part of 
this is the requirement that the consumer have at least two address books, on at least two 
personal information management applications. Hertzog refers to this limitation by 
saying that "the first and second personal informations are not simultaneously validated 
for access by the personal information management application", which is another way of 
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saying the consumer can't be logged in on both at the same time (see, e.g., Hertzog claim 
1, 6, and 10 or Hertzog paragraph 0062). 

Since the present disclosure does not require a consumer-based application, let alone two 
or more consumer applications, Hertzog's requirement has no logical analog in the 
present disclosure. These are not requirements of the present disclosure, and, hence, 
Hertzog and Smith teach away from the present disclosure. 

5. ) Hertzog implicitly requires that each database entry for an entity include a name 

and this requirement teaches away from the present disclosure. 

Since Hertzog deals with a consumer being able to synchronize their personal address 
book using a Rolodex-like virtual address card, Hertzog implicitly requires that each 
address card have a corresponding name attached to it. Hertzog's entire system is useless 
without a name on each address card. See, e.g., Hertzog, Figures 8-10, 12, 14, 19, and 
20. After all, all Hertzog searches return a virtual card to a GUI for viewing by a human. 
Without being able to see a name, a user would find the system useless. 

The present disclosure's primary embodiment teaches for a query of a piece of contact 
information, such as an Email address, to be processed with the database, and to return 
another Email address. No name is required. No virtual card is required. No human 
viewing is required. 

These are not requirements of the present disclosure, and, hence, Hertzog and Smith 
teach away from the present disclosure. 

6. ) Hertzog's requirement, of a sighted human being looking at a GUI, teaches away 

from the present disclosure. 
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Since Hertzog deals with a consumer being able to synchronize their personal address 
book using a Rolodex-like virtual address card, Hertzog implicitly requires that a human 
being is able to look at the virtual cards on a GUI and type in changes. 

As noted above, Hertzog requires a personal information management application that is 
to be synchronized with a central, remote database (a "server database, 34": see Hertzog 
paragraph 0050) and the virtual cards that make up the database be able to be seen by a 
human user on a GUI. Smith's disclosure, on the other hand, deals with authentication 
procedures for being able to access a database. Whether apart or together, these citations 
teach away from the present disclosure in that they require a sighted (non-blind) human 
being be able to look at the output of Hertzog's database inquiries. 

Moreover, Hertzog's disclosure does not work without a computer monitor; Hertzog's 
disclosure does not work without a computer monitor that is on and functioning and 
connected to a computer running a personal information management application; and 
Hertzog's disclosure does not work if a human being is not sitting in front of the monitor 
displaying a personal information management application with their eyes open and 
conscious. 

All of these are not requirements of the present disclosure, and, hence, Hertzog and Smith 
teach away from the present disclosure. 

7.) Hertzog's requirement of a typed word search teaches away from the present 

disclosure. 

As noted above, Hertzog inherently requires that a person sitting a computer, looking at a 
personal information management application on a GUI, type in a word search in a dialog 
box and get back a search result, in the form of another dialog box (see, e.g., Hertzog, 
paragraph 1 10 for a discussion of the "power find panel"). The next intrinsically required 



37 of 53 



Appl. No. 10/605,488 

REVISED Amdt. dated 28 FEBRUARY 2007 
Reply to Office action of 5 June 2006. 

step is that the person look at the results and decide for themselves what alternate contact 
points there are for the person listed on the virtual card in the results. 

These inherent requirements teach away from the present disclosure, which has no 
requirements of a personal information management application, no GUI, no dialog 
boxes, no user sitting at a computer which is running a personal information manager 
application, no decision by a person as to what alternate contact points there are on a 
card. 

In order for Hertzog to make his disclosure work for a human sitting at a computer 
screen, he included a word search function in a dialog box. This teaches away from the 
present disclosure which does not have such limitations or requirements. 

This, in combination with Smith, would teach away from the present disclosure. 

IV. AMENDMENTS TO THE SPECIFICATION: 

The attached amendments to the specification are entirely typographical, such as deleting 
erroneous character artifacts, and inserting proper paragraph breaks. Two paragraphs 
have been amended to add references already implied by the text. 

All changes are non-substantive and are merely for clarity. 

V. AMENDMENT TO CLAIMS: 

Claims 1, 13, 23, 25, 27, 30, and 31 were amended. 

Claim 30 has been amended to reflect that it refers to the preceding claim, Claim 29, 
rather than Claim 25. Claim 30's citation of "said changed data elements" refers to the 
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prior claim, Claim 29, not Claim 25, as originally stated. Claim 25 contains no "changed 
data elements" reference. This is a non-substantive correction of a typographical error. 

Claim 3 1 has been amended to correct a typographical error, which is non-substantive in 
nature: the agreement of an article to its subject noun. 

VI. AMENDMENTS TO THE DRAWINGS: 

The Examiner has objected to all drawings, stating that "the drawings must show every 
feature of the invention specified in the claims. . . ." This is not a requirement under law. 
35 USC section 1 13 provides that the applicant may furnish drawings "where necessary 
for the understanding of the subject matter sought to be patented." Further, according to 
the MPEP, "[i]t has been USPTO practice to treat an application that contains at least one 
process or method claim as an application for which a drawing is not necessary for an 
understanding of the invention. . .." MPEP 601 .01(f). As such, the Examiner is incorrect. 

In the present disclosure, Figures 3 through 1 8 could have been included in the body of 
the specification, as tables or non-text elements of the specification. MPEP 
608. 01. 1. (b)(6). The Applicant is willing to amend the specification to insert those tables 
into the body of the specification, if the Examiner so desires. The Applicant asks for 
leave to so amend if this is so requested. This would be a non-substantive change. As 
such, the Applicant asks that the Examiner withdraw the objections to those figures. 

Replacement drawings for Figures 1-2 and 15, 15A, 15B, and 16 are attached to this 
document. 

VII. CONCLUSION 
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For the reasons stated above, the Applicant asks that the Examiner enter the amendments 
contained herein, withdraw all rejections with respect to the claims, and allow the 
application to issue as a patent. 

Thank you, 
Sincerely, 




Ed Skoch 
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AMENDMENTS TO THE SPECIFICATION: 

Please replace paragraphs [0139] and [0140] with the following amended paragraphs: 

[0139] Fig. 15 illustrates a flow chart of the logical decision making steps of a 
preferred method of maintaining the Database, as used in an Identifier Module, 24, and 
a Merger Module, 28. Each record of the received dataset is preferably processed by 
sequentially performing: an Email Address Test, a Recipient Test, a Postal Address 
Test, and a Name Test. In the method shown in Fig. 15, the data records are analyzed 
individually to determine and store all the associations between various data elements 
contained in the records. To simplify the explanation, this discussion will describe a 
Database that stores names, postal addresses, and Email addresses. However, it can 
easily be extended for any other type of PII such as phone numbers, etc. (And, as 
noted above, the invented method does not require the Database to contain more than a 
single type of PII.) As discussed previously, a preferred method to identify and store 
PII would b e us e to a database template with the following population: 

[0140] ddRecipient—Has one record per uniquely identified Recipient. 

Please replace paragraphs [0173] and [0174] with the following amended paragraphs: 

[0173] Fig. 16 illustrates the steps of a second data-inputting method for embodiments 
of the present invention, wherein the data structure of the Database consists of a single 
table, where each row or record comprises at least three elements of PII: preferably, an 
Email address, a postal address, and a Recipient'^ name (for example, see FIG. 4). 
Each element of information may be represented by one or more fields in the table. For 
example, postal addresses may be comprised of the following fields: street address, 
city, state, and postal code. The advantage of such a simple table is the speed with 
which Database searching occurs, as well as ease of maintenance of the data. Received 
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data records are preferably prepared in a standardized format (step 94) either at the 
Data Provider, or in the Receiver Module of the Data Manager. Each element and field 
is standardized, once records having missing or invalid elements are discarded (step 
92) in the Receiver Module . 

[0174] Such standardization (step 94) makes comparison a simple matter of comparing 
PII elements (i.e., a complete data record), and having a simple pass/fail test in the 
Identifier Module (step 96) regarding the matching of the received data versus data 
already in the Database. If the record is not in the Database, it is added (step 98) by the 
data Merger Module . Otherwise, the next record is loaded and the process is repeated. 

Please add the following new paragraph after paragraph [0139]: 

[0139.1] As discussed previously, a preferred method to identify and store PII would 
be use to a database template with the following population: 
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AMENDMENTS TO THE CLAIMS: 

This listing of claims will replace all prior versions, and listings, of claims in the 
application: 

Listing of Claims: 

CLAIM 1. (CURRENTLY AMENDED) A system for returning contact information 
of one type in response to a query having different contact information of the same 
type, for the same entity, comprising: 

a) a data storage means device for storing data; 

b) a database of contact information for a plurality of entities, which resides in said 
data storage means device ; 

c) a first means for receiving one or more queries, each comprising at least one 
element of contact information for each entity; 

d) a second means for accessing and searching said database that 

(dl) compares the contact information in said query to the contents of said 
database, (d2) identifies contact information in said database related to said entity 
in said query, and (d3) identifies alternate contact information of the same type as 
said query which is related to the entity; and 

e) a third means for responding to queries that returns^ a response to said query, 
comprising different contact information of the same type as said query, said 
different contact information corresponding to the same entity as said query , and 
said response comprising data in a computer readable, computer storable, and 
computer transmittable format and capable of being returned to the originator of 
the query . 

CLAIM 2. (ORIGINAL) A system, as in Claim 1, wherein said second means further 
comprises: 
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a) a means for searching said database for the existence of a first type of contact 
information which is contained in said query; 

b) a means for identifying contact information of a second type which is related to 
the same entity as said query; 

c) a means for searching through said database, using said second type of personal 
contact information; and 

d) a means for identifying, in the database, alternate contact information of the 
first type in said query which is related to said second type of personal contact 
information, for the same entity. 

CLAIM 3. (ORIGINAL) A system, as in Claim 2, wherein the second means further 
comprises a means for repeating said searching and said identifying means, until all 
related contact information of the type in said query for said entity is identified in said 
database. 

CLAIM 4. (ORIGINAL) A system, as in Claim 1, wherein the third means further 
comprises a means for selecting a single one amongst more than one alternate contact 
information elements of the same type as said query if a single result per entity is 
required and if more than one alternate contact point is found. 

CLAIM 5. (ORIGINAL) A system, as in Claim 1, wherein the contact information 
type of said query and the returned data is an Email address. 

CLAIM 6. (ORIGINAL) A system, as in Claim 2, wherein the contact information 
type of said query and the returned data is an Email address. 

CLAIM 7. (ORIGINAL) A system, as in Claim 3, wherein the contact information 
type of said query and the returned data is an Email address. 
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CLAIM 8. (ORIGINAL) A system, as in Claim 4, wherein the contact information 
type of said query, the alternate contact information elements, and the returned data is 
an Email address. 

CLAIM 9. (ORIGINAL) The system according to Claim 1, wherein the system further 
comprises a means for obtaining permission from the entity in said query, prior to the 
response to said query. 

CLAIM 10. (ORIGINAL) The system according to Claim 2, wherein the system 
further comprises a means for obtaining permission from the entity in said query, prior 
to the response to said query. 

CLAIM 11. (ORIGINAL) The system according to Claim 3, wherein the system 
further comprises a means for obtaining permission from the entity in said query, prior 
to the response to said query. 

CLAIM 12. (ORIGINAL) The system according to Claim 4, wherein the system 
further comprises a means for obtaining permission from the entity in said query, prior 
to the response to said query. 

CLAIM 13. (CURRENTLY AMENDED) A method for returning contact information 
of one type in response to a query having different contact information of the same 
type, for the same entity, comprising the steps of: 

a) accessing a database of contact information of a plurality of types 
corresponding to a plurality of entities; 

b) comparing said first type of contact information in said query with the contents 
of said database; 

c) if said first type of contact information in said query is included in said 
database, identifying contact information of a second type in said database, which is 
related to said first type of contact information in said query; 
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c2) identifying, in said database, one or more alternative contact information 
elements of the first type related to the entity in said query by using said second type 
of related contact information to search said database; 

c3) generating , and storing in a tangible medium, a response to said query which 
includes the identified alternate contact information of the first type related to said 
entity in said query , said response comprising data in a computer readable, computer 
storable, and computer transmittable format and capable of being returned to the 
originator of the query ; and 

d) generating a response indicating that alternate contact information of the first 
type for said entity is not included in said database, if this is the case , and said 
response comprising data in a computer readable, computer storable, and computer 
transmittable format and capable of being returned to the originator of the query . 

CLAIM 14. (ORIGINAL) A method, as in Claim 9, further comprising the steps of 
repeatedly searching the database, using said second type of contact information and 
alternate contact information of said first type for repeatedly searching said database, 
until all related contact information of said first type for said entity is identified in said 
database. 

CLAIM 15. (ORIGINAL) The method according to Claim 9, further comprising the 
step of obtaining permission from said entity, prior to said response to said query. 

CLAIM 16. (ORIGINAL) The method according to Claim 11, wherein the step of 
obtaining permission from said entity comprises the additional steps of: 

1) generating and transmitting a permission request to said entity; 

2) obtaining permission from said entity; and 

3) discarding contact information for said entity from said response, if said 
permission is not obtained. 
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CLAIM 17. (ORIGINAL) The method, according to Claim 9, further comprising the 
additional step of identifying the single alternate contact information element which is 
most beneficial to the initiator of the query, prior to generating a response to said 
query, if more than one contact information element of said first type is identified in 
the database. 

CLAIM 18. (ORIGINAL) The method, according to Claim 9, wherein the first type of 
contact information in said query and the alternate contact information in said 
response are Email addresses. 

CLAIM 19. (ORIGINAL) The method, according to Claim 10, wherein the first type 
of contact information in said query and the alternate contact information in said 
response are Email addresses. 

CLAIM 20. (ORIGINAL) The method, according to Claim 1 1, wherein the first type 
of contact information in said query and the alternate contact information in said 
response are Email addresses. 

CLAIM 21. (ORIGINAL) The method, according to Claim 12, wherein the first type 
of contact information in said query and the alternate contact information in said 
response are Email addresses. 

CLAIM 22. (ORIGINAL) The method, according to Claim 13, wherein the first type 
of contact information in said query and the alternate contact information in said 
response are Email addresses. 

CLAIM 23. (CURRENTLY AMENDED) A method for returning contact information 
of one type in response to a query having different contact information of the same 
type, for the same entity, comprising the steps of: 
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a) accessing a database, said database having been populated with a plurality of 
contact information corresponding to a plurality of entities; 

b) comparing said contact information in said query with said plurality of contact 
information in said database; 

c) if the contact information in said query is included in said database, identifying 
an entity in said database that matches the entity in said query and is associated with 
the contact information in said query; 

c2) identifying all the other alternate contact information of the same type as in 
said query associated with the entity in said database; 

c3) generating , and storing in a tangible medium, a response to said query which 
includes the alternate contact information identified for the entity in the query , said 
response comprising data in a computer readable, computer storable, and computer 
transmittable format and capable of being returned to the originator of the query , and 

d) generating a response indicating if alternate contact information for the entity 
in said query is not included in said database , said response comprising data in a 
computer readable, computer storable. and computer transmittable format and 
capable of being returned to the originator of the query . 

CLAIM 24. (ORIGINAL) The method, according to Claim 19, wherein the contact 
information in said query and the alternate contact information in said response are 
Email addresses. 

CLAIM 25. (CURRENTLY AMENDED) A system for populating and maintaining a 

contact information database comprising: 

a) a database in a computer storage device containing a plurality of contact 
information for a plurality of entities, said contact information being associated with 
the appropriate entity and said contact information comprising an Email address and 
at least one from the group consisting of an Email address, a name, a postal address, 
a governmentally issued identifying number, a birth date, and a telephone number; 
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b) a receiver for receiving one or more datasets, each dataset having a plurality of 
contact information, said contact information comprising at least two from the group 
consisting of an Email address, a name, a postal address, a governmentally issued 
identifying number, a birth date, and a telephone number; 

c) an identifier for identifying selected data from the dataset to be merged into 
said database; and 

d) a data merger module for merging , and storing in a tangible medium, selected 
data into said database. 

CLAIM 26. (ORIGINAL) The system according to Claim 21, wherein the system 
additionally comprises a computing device for controlling said database, said receiver, 
said identifier, and said data merger module. 

CLAIM 27. (CURRENTLY AMENDED) A method for populating and maintaining a 
contact information database, comprising the steps of: 

a) establishing a database in a computer storage device having a plurality of first 
data records, said first data records comprised of an Email address and an associated 
contact information element said contact information element comprises at least one 
from the group consisting of: an Email address, a name, a postal address, a 
governmentally issued identifying number, a birth date, and a telephone number; 

b) receiving one or more datasets, each dataset having a plurality of second data 
records, said second data records including at least two from the group consisting of 
an Email address, a name, a postal address, a governmentally issued identifying 
number, a birth date, and a telephone number; 

c) identifying selected data from said second data records to be merged into said 
database; and 

d) mergin g, and storing in a tangible medium, said selected data into said 
database. 
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CLAIM 28. (ORIGINAL) The method according to Claim 23, wherein the step c) of 
identifying selected data further comprises the steps of: 

cl) comparing each data record of each dataset with the contents of said 
database; and 

c2) identifying and selecting any data that does not exist in said database to be 
merged into said database. 

CLAIM 29. (ORIGINAL) The method according to Claim 23, wherein the step c) of 
identifying selected data further comprises the steps of: 

cl) comparing each record of each dataset with a previously received version of 
the record, if such version exists; 

c2) determining whether any of the data elements pertaining to a entity in the 
dataset have changed since the previously received of the record; and 

c3) selecting changed data elements for merging into said database. 

CLAIM 30. (CURRENTLY AMENDED) A method, as in Claim 25-29, wherein said 
changed data elements for merging into said database are Email addresses. 



CLAIM 31. (CURRENTLY AMENDED) The method according to Claim 23, wherein 
the step c) of identifying selected data further comprises the steps of: 

cl) grouping each record of each dataset with other records in the dataset and/or 
records in the database by contact information other than an Email address that can 
be used to identify a entity; 

c2) identifying records that share the same data elements used in cl) but have 
different Email addresses; and 

c3) selecting the multiple email addresses identified for a an entity for 
merging into said database. 
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CLAIM 32. (ORIGINAL) The method according to Claim 23, wherein the step c) of 
identifying selected data further comprises the step of identifying all received data 
records as candidates for merging in the database. 

CLAIM 33. (ORIGINAL) The method according to Claim 23, wherein the step c) is 
performed in a computing device. 

CLAIM 34. (ORIGINAL) The method according to Claim 23, wherein the step c) of 
identifying selected ones further includes a step of comparing similar, but inexact, 
contact data elements to determine if the data elements are equivalent. 

CLAIM 35. (ORIGINAL) The method according to Claim 23, wherein the step d) of 
merging the selected contact information elements comprises an additional step of 
inserting each one of plurality of selected contact information elements and 
relationships between contact information elements and entities into said database. 

CLAIM 36. (ORIGINAL) The method according to Claim 23, further comprises the 
steps of: 

e) periodically receiving a plurality of datasets, each dataset having a plurality of 
second data records; and 

f) repeating step c) through e). 



51 of 53 



Appl. No. 10/605,488 

REVISED Amdt. dated 28 FEBRUARY 2007 
Reply to Office action of 5 June 2006. 



AMENDMENTS TO THE DRAWINGS: 



The attached sheets of drawings include changes to Figures 1, 2, 15 A, 15B, and 16. The 
sheet with Figures 1 and 2 replace the original sheet which had Figures 1 and 2. 
Elements present in the specification were added to the drawings for clarity. No 
substantive changes were made. 
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